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INTERNET PAYMENT SYSTEM AND METHOD 

Cross-reference to Related Applications 

This application is related to a first provisional patent application filed with 
the US patent office under application number 60/422,640 with filing date 1 1/01/2002 
and a second provisional patent application filed with the US patent office under 
application number 60/506,873 with filing date 09/30/2003. 

Field of the Invention 

The present invention relates to an Internet payment system and method. 

Background of the Invention 

Currently users who have purchased goods and services over the Internet are 
faced with few payment options. The credit card companies dominate the market, 
while the users pay high processing fees and shy away from making online payments 
for trust and security reasons. Digital cash has lower rates than credit card companies, 
but the adoption has been slow and the solutions in place .are still not turnkey. 
Following is a list of few problems that are imposed by the current methods: 

a) Credit Card fraud deters users from using their credit card numbers on 
the web; 

b) High cost of processing deters merchants from setting up eCommerce 
sites; and 

c) Inability to buy items from multiple merchants with one payment 
transaction makes the process cumbersome. 

Summary of the Invention 

An object of the present invention is to provide an improved Internet payment 
system and method. 
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A payment method and system using electronic media and in particular the 
Internet to allow a secure and trusted exchange of money, to broaden the choices of 
users and allow merchants to receive payment using means other than credit cards and 
5 digital cash, to reduce the cost of electronic transactions for both user and merchant 

and to allow users to make payment for multiple merchants using a single account. 

The Internet Debit Manager (IDM) functions as a payment processing 
infrastructure, that processes online purchases completed by buyers via web banking, 
10 telebanking and mobile banking. The present invention supports purchase processing, 
payment processing, as well as service provider and merchant tools. The system is 
able to clear and settle funds for both the buyers as well as merchants participating in 
transactions. 

The system enables secure confidential debit payment for goods and services 
15 purchased over the Internet. The system has flexible payment handling and supports 
payment flow from the bank to the service provider to the merchant or directly from 
the bank to the merchant. 

The system allows consumers to shop online and at the time of checkout select 
direct payment from an account as the payment option. A bill is automatically 

20 displayed and emailed to the customer. The customer pays the bill at their bank the 
same way they pay their utility bill, which then results in a payment confirmation sent 
from the bank to the payee. Payment information from the bank is sent to the system 
manually by the service provider administrator using the Debit Manager interface or 
by running an automated batch process to update the purchase transactions. Once the 

25 payment information is processed the customer and merchant accounts are balanced 
and both receive automatic notification of the payment. The system also advises if 
underpayment or overpayment has been made. The system handles errors scenarios 
during the processing of the transaction and notifies customer, merchant or service 
providers with the necessary error codes and appropriate action that needs to be taken. 
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In accordance with an aspect of the present invention there is provided an 
apparatus for Internet payment comprising: a service layer including a presentation 
view and a merchant interface; a process layer including business logic and data 
conversion modules; and a business component layer including user authentication, 
5 transaction processing, payment manager, business-to-business interface and sales 
tools modules. 

In accordance with another aspect of the present invention there is provided an 
Internet payment method comprising the steps of: creating user and merchant 
accounts; receiving from a user a selection of web banking as a payment option; 
10 creating and sending an electronic bill for the user representing a user account and a 
merchant account; receiving a transfer of electronic data from a banking institution, in 
response to a payment request by the user; parsing of electronic data received; 
updating a database using the parsed data; settling the user account; settling the 
merchant account; and sending confirmations of payments to both user and merchant. 

15 

Brief Description of the Drawings 

The present invention will be further understood from the following detailed 
description with reference to the drawings in which: 

20 Fig. 1 illustrates in a functional block diagram an on-line direct debit payment 

system in accordance with an embodiment of the present invention; 

Fig. 2 illustrates the modules of the system of Fig. 1 used to process a 
purchase transaction; 

25 

Fig. 3 illustrates the modules of the system of Fig. 1 used to process a 
payment transaction; 

Fig. 4 illustrates the modules of the system of Fig. 1 used to send a message; 
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Fig. 5 illustrates the modules of the system of Fig. 1 used to provide business- 
to-business transactions; 

Fig. 6 illustrates communication with the system of Fig. 1 for a typical end 
user purchase; 

Figs. 7a, 7b, and 7c illustrate in flow charts set up, purchase and payment 
processes for the system of Fig. 1; and 

Fig. 8 illustrates communication with the system of Fig. 1 for Internet card 
loading. 

Detailed Description of the Preferred Embodiment 

Referring to Fig. 1, there is illustrated in a functional block diagram an on-line 
direct debit payment system in accordance with an embodiment of the present 
invention. 

Fig. 1 illustrates in a functional block diagram the on-line direct debit payment 
system in accordance with an embodiment of the present invention. The system 10 
includes a Service Layer 12, Process Layer 14 and Business Components Layer 16 
that communicate with a database 18. 

The service layer 12 includes a presentation view 20 having a merchant 
administration module 22, a service provider administration module 24, a consumer 
wallet 26 and a forms module 28. The service layer 12 also includes a merchant 
interface 30 having a merchant integration API module 32, a business-to-business 
(B2B) interface 34. The service layer also includes a payment interface 36. 

The process layer 14 includes business logic and data conversion and shares 
persistent objects 40 and 42 with the service layer 12 and business component layer 
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16, respectively. Business logic layer acts as a messenger between the service layer 
and business component layer. It takes requests from service layer, performs first 
level validations on inputs, does data conversion on the inputs and passes it on to the 
business component layer for further validations and data storage functions. 
5 This layer takes responses from the business component layer and passes it to the 
Services layer in the appropriate formats 

The business component layer includes a user authentication module 44, a 
transaction processing module 46, a payment manager module 48, a B2B interface 50 
10 and a sales tool module 52. The payment manager 48 includes a debit manager 
module 54, an account settlement module 56, a messaging manager module 58 and a 
billing manager 60. The B2B interface 50 includes a configuration manager 62, a 
scheduler 64 and a secure transfer module 66. 

15 Referring to Fig. 2, there is illustrated the modules of the system of Fig. 1 used 

to process a purchase transaction; 

The modules of the system that interact to process a purchase transaction are 
shown in Fig. 2. The modules include the merchant integration API module 32, the 
20 user authentication module 44, the transaction processing module 46, the debit 
manager module 54, the account settlement module 56, and the messaging manager 
module 58. 

The Merchant API receives information in an html post, XML or client server 
25 secure interface. The information must include the merchant identification and at least 
one purchase item. Each purchase item must have a positive dollar value attached to 
it. The transaction must also include all mandatory fields and correct field formats as 
defined by the Merchant Integration API. 

30 The general format of the purchase information passed to the IDM system in 

the HTML post is shown below: 
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<form action=https://www.modasolutionsxom/MODAPay/ProcessPaymem " 
method="POST"> 

<input type=hidden name=merchant_id value="MP0001"> 
<input type=hidden name=item_name_l value="computer"> 
<input type=hidden name=item_desc_l value="DELL Dimension"> 
<input type=hidden name=item_amount_l value-' 1400"> 
<input type=hidden name=item_quantity_l value="l"> 
<input type=hidden name=item_name_2 value="Monitor"> 
<input type=hidden name=item_desc_2 value-'Samsung 14" LCD"> 
<input type=hidden name=item_amount_2 value="1400"> 
<input type=hidden name=item_quantity_2 value="r'> 
<input type=hidden name=item_count value="2"> 
<input type=hidden name=currency value="CAD"> 
<input type=hidden name=cmd value- '_mTrans"> not to be changed 
</form> 

The system 10 is capable of processing single or recurring payment. For 
recurring payments the frequency of the payments must also be passed to the system. 
The payment schedule is stored^ in the database. The billing manager is invoked 
20 periodically and searches due bills and sends the information to the messaging 
manager to prepare and deliver the necessary bills. For single billing, the transaction 
process invokes the billing manager real-time. 

The system 10 is capable of managing overdue accounts. To enable this 
25 feature the information passed must include overdue account information indicating 
the terms of sales to be applied to overdue accounts. The billing manager 60 applies 
this information to any reminder bills generated. For example a merchant may pass 
net "30, 1.5%, overdue reminder=yes". After thirty days if the account remains unpaid 
an ebill reminder will be sent including the 1.5% interest charges against the 
30 transaction. 
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System generated errors are returned to the system or presented to the user. 
Either the user or the merchant's system administrator must correct the error in order 
to proceed with the purchase. 

5 The system 10 includes a user Authentication Module 44. Prior to the system 

committing a sales transaction to the database the customer information is passed to 
the authentication module 44. The user authentication module 44 is passed the 
customer information. If the customer is a new user the user authentication module 44 
of the system creates an account, the system returns the account and password 
10 information for the customer to accept. 

Referring to Fig. 3, there is illustrated the modules of the system of Fig. 1 used 
to process a payment transaction; 

15 The system is also capable of receiving bulk purchase information in a batch 

process. This information is passed through the Merchant Interface 32 to the system 
via html or xml. The system processes batch purchases the same way it processes 
individual requests made to the Merchant Interface API. 

20 The modules of the system that interact to process a payment transaction are 

shown in Fig. 3 blue. These modules include the merchant administration module 22, 
the payment interface 36, the process layer 14, the debit manager module 54, the 
account settlement module 56, the messaging manager module 58 and the database 
18. 

25 

In one embodiment, the payment information is received electronically and is 
processed by the system. The Payment Interface 36 receives payment information in 
an electronic feed from the banks. The Payment Interface 36 may be configured to 
receive the files and information in different formats to accommodate different banks. 
30 The payment interface 36 parses the information to ensure that it is in the predefined 
bank format. The parsing of the information may be triggered manually through the 
merchant administration view 22 or scheduled to run at different intervals. 
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All generated errors are written to a log file. The errors must be corrected in 
order to proceed with the processing of the payment file. 

5 The Account Settlement module 56 processes all valid payment transactions 

by extracting the data and populating the database 18. The system is capable of 
managing correct payments, overpayment and underpayment. The transactions are 
processed as follows: 

10 When the amount received equals the amount owing in the customers account 

all transactions are processed, and marked as Paid. 

When the amount received is larger than the amount owing on the customer 
account all transactions are credited and their status is changed to Paid. The account 
1 5 balance will reflect the unused. 

When the amount received is less than the total amount owing on all 
transactions the Account Settlement module processes the transactions starting with 
the transaction that was purchased first, money is credited to each transaction and 
20 marked as Paid. Unpaid transactions retain their status as payment pending. The 
customer account carries a balance if the were insufficient funds to cover the bill. 

The payment process triggers the Messaging Manager module 58 to notify the 
user that a payment has been received, the status of the account and if further action is 
25 required on their part to complete the transaction. 

In a second embodiment, the payment information is received by fax and 
entered into the system manually. The transactions are manually typed into the Debit 
Manager 54 by entering the account number and amount received from the bank. The 
30 system then processes the transactions the same way it processes the electronic feeds. 
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Referring to Fig. 4, there is illustrated the modules of the system of Fig. 1 used 
to send a message. 

The system includes a module known as the Messaging Manager 58. As 
5 shown in Fig. 4 the messaging manager 58 receives system calls from the Merchant 
Interface 22, Account Settlement module 56 and Billing Scheduler 60 to trigger the 
sending of a message. 

The system call includes parameters such as message type, message format, 
10 preconfigured account number and transaction reference number. Based on these 
parameters the message manager 58 queries the database 18 for the content of the 
message. 

The type of messages generated by the messaging manager 58 are eBill, 
15 Payment Reminder, Payment Received, Over Payment, Insufficient Payment, and 
Coupons, Order Cancellation or Amendment. The content of each of the messages 
may be system default or composed using the merchant interface and stored in the 
database. The automatic sending of a message may be suppressed. The messaging 
manager 58 sends email, SMS and MMS formats. 

20 

An embodiment of the invention further includes a method of facilitating 
customers to manage their account funds using the Consumer Wallet 26 in an internet 
browser. The Consumer Wallet 26 queries the database 18 to present a history of 
transactions, a list of outstanding transactions and the account balance. Available 
25 funds can be allocated to unpaid bills and the Account Settlement module 56 updates 
the database. Bills that have been completed successfully are marked as Paid. The 
remaining balance is credited to the customers account; outstanding transactions 
remain as payment pending. 

30 Using the GUI interface a customer can choose to allocate funds manually or 

configure the Account Settlement module to allocate money on their behalf using a 
First in first out (FIFO) system. When the "Allocate Funds Manually" option is 
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enabled, then each time a payment transaction is processed the Messaging Manager 
sends the customer an email instructing the customer to log on to the system to 
complete the transaction by allocating the funds appropriately. 

5 The system includes a module known as the Service Provider Administration 

Tool 24. The Service Provider admin is an application accessed through an internet 
browser that allows authorized administrators to view and manage the information 
stored in the database. 

10 The Service Provider Administration provides the following functionality: 

1. View, search, sort, and edit merchant account information belonging to 
that Service Provider, setup and tear down merchant accounts. 

2. View, search, sort transaction information generated by their 
merchants 

15 3. View, search, sort customer account information. 

4. Generate merchant statements 

5 . Reconcile settlement with merchants : 

a. Retrieve records of all payments received for a specified period 
of time 

20 b. Flag transaction records as "reimbursed" when payments of 

funds have been reimbursed to the merchants. 

The system includes a module known as the Merchant Administration Tool 
22. The Merchant admin is an application accessed through an internet browser that 
25 allows authorized administrators to view and manage the information stored in the 

database. 

The Merchant Administration provides the following functionality: 

1 . View, search, sort, and edit customer account information belonging to 
30 that Merchant, setup and tear down merchant accounts 

2. View, search, sort transaction information generated by their customer 

3. Perform bill adjustments 
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4. View, search, sort customer account information 

5 . Generate customer statements 

6. Generate and configure message manager 

7. Reconcile settlement with payees: 

a. Retrieve records of all payments received for a specified period 
of time 

b. Retrieve records of all payments reimbursed by the payee for a 
specified period of time. 

In an embodiment of the system the merchant administration enables 
merchants to make adjustments to existing bills. The bill adjustment includes bill 
presentment to the administrator and the functions to perform order cancellations, 
item cancellation, and item modifications. Adjustments to orders can trigger the 
account settlement module to make the required changes to the customer account 
when billing is affected. The message manager can be automatically or manually 
invoked to send notification of the change to the customer. 

Another embodiment of the invention includes a system for generating and 
settling coupons. The system comprises of an interface to create and manage the 
coupons, a database to store coupon details and the method that enables merchants to 
send coupons once the eBill has been received by the buyer. A coupon contains the 
customer account and the discount amount that is applied to a purchased or left in the 
account for future purchases. The interface accepts individual coupons or batch 
loading of coupons into the system. When a payment is processed the Account 
Settlement module searches the database for coupons that are linked to the customer 
account and applies the discount to settle the account balance. 

Referring to Fig. 5, there is illustrated the modules of the system of Fig. 1 used 
to provide business-to-business transactions. 

The system includes a module known as the B2B Interface 50 that interfaces 
on the backend with third party applications such as sales order processing and 
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accounting systems residing in the merchants' premises. The order processing 
information is exported off the system over and HTML or XML interface 34. As 
shown in Fig. 5 below the B2B Interface includes three components as follows: 

1 Configuration Module 62 
5 2 Scheduler Module 64 

3 Secure Transfer Module 66 

The configuration module 62 is used to record in the database the batch 
processing triggers, information to be transmitted, interface destination, output 
10 formats and error handling destination. 

The scheduler 64 runs to invoke the secure transfer of the order information on 
a scheduled basis. The secure transfer module 66 establishes a secure link with the 
host destination. A file is created and the information is transferred to the host 
15 destination. 

Referring to Fig. 6, there is illustrated communication with the system of Fig. 
1 for a typical end user purchase. 

20 Purchase processing supports an API to accept user authentication information 

and purchase transaction details from a shopping cart or other web application such as 
an invoicing or event management application. Purchase processing also enables 
posting of transaction information to the IDM database, and triggers electronic bill 
delivery and electronic receipt delivery. 

25 

Payment processing allows processing by batch or individually of bank 
payment logs. Payment processing also allows customers to allocate funds to 
purchases as desired when multiple pending payments exist. Processed payments can 
trigger automatic notification of incomplete payment, over payment and full payment 
30 received. 
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Merchant tools allow merchants to view, search and sort transactions, manage 
sales transactions, export data from the IDM system , generate notification and 
marketing messages over SMS, email, NMS or instant messaging, generate coupons, 
and create pre-assigned customer accounts. 

5 

Service Provider tools allows administrators to view, create and maintain 
merchant and user accounts and settle merchant reimbursements. 

Referring to Figs. 7a, 7b, 7c, there are illustrated in flow charts set up, 
10 purchase and payment processes for the system of Fig. 1 respectively. A method that 
enables a payee to be configured on the system and setup as a payee at the bank is 
illustrated in Fig. 7a, 100 as follows: Configure service provider as a payment 
receiver- IDM Service Provider registers itself as a payment receiver with all major 
banks. This process is only performed once before the system is deployed. At the 
15 completion of this step any person can visit their banks web page, mobile banking or 
telebanking and search for the payee name. Once the company information is 
displayed a user adds payee to their bill list. 

Alternatively, Merchant as payee- The Merchant registers itself as a payment 
receiver with all major banks. This process is only performed once before IDM is 
20 deployed. At the completion of this step any person can visit their banks web page, 
mobile banking or telebanking and search for the merchant. Once the company 
information is displayed a user adds the merchant to their bill list 

Currently all transaction processing software components are only capable of 
processing payments based on one account - one merchant basis. For example each 
25 Utility company creates an account number for each client, which limits the client to 
only pay that particular utility. The system leverages the existing, banking 
infrastructure and improves it by allowing users to pay multiple merchants using one 
account. 
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A method that enables a merchant to be configured on the system is illustrated 
in Fig. 7a, as follows: A merchant that wishes to offer web banking as a payment 
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option for online purchases of goods or services contacts the service provider to 
receive integration information. Once the registration form is completed the 
information is setup on the system database and a unique account id and number 
identifying the merchant is assigned 102. 

2. Each merchant may assign one or more administrators to maintain support of 
the system and to track and manage transactions. All administrators are given access 
to a sophisticated reporting and management tool. 

3. A merchant has two system interface options based on their level of 
sophistication and size of business: 

a. Use wed banking with IDM Service Provider online order form 28 

b. Integrate web banking with shopping cart software using the Merchant 
Integration API, 104 

4. The merchant must choose the payee: 

a. The Service provider will be the payee. The customer will make their bill 
payments to Service Provider, the bank will pay the Service Provider, which will then 
reimburse the merchants. 

b. The merchant will be the payee. The customers will make their bill payments 
directly to the merchant and the bank will pay the merchant. 

Fig. 7b, illustrates in a flow chart the purchase process. The method provided enables 
merchants to accept debit payments for online purchases as follows: 

1. A user visits the merchant website 1 10 and selects the goods or services they 
wish to purchase. Once the user decides to proceed to checkout and selects direct 
payment from account as the payment option the transaction information is posted 
1 12 to the IDM system via the Merchant Integration API. 

2. The Merchant Integration API allows external parties (customers, suppliers or 
partners) to use the IDM for processing of payment. The API can be made public and 
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offered as open source or it can be sold for a fee. The API will have calls to the IDM 
and will serve as a way to hide the inner details of the engine from the outside world. 

3. Each Transaction must include the merchant identification and at least one 
purchase item. Each purchase item must have a positive dollar value attached to it. 

5 The transaction must also include all mandatory fields and correct field formats as 
defined in by the Merchant Integration API. 

4. The information passed may include the payment occurrence indicating 
whether the transaction is a single payment or re-occurring payment and the type of 
the transaction Test or Live. For re-occurring payment the frequency of the payments 

10 must also be passed to the EDM system. 

5. The information passed may include overdue account information indicating 
the terms of sales to be applied to overdue accounts. This information will be applied 
to any reminder bills generated. For example a merchant may pass net "30, 1.5%, 
overdue reminder=yes". After thirty days if the account remains unpaid an ebill 

1 5 reminder will be sent including the 1.5% interest charges against the transaction. 

6. Errors 1 14, 1 16 are returned to the system or presented to the user. Either the 
user or the merchant's system administrator must correct the error in order to proceed 
with the purchase. 

7. The customer is then authenticated as a user of the payment system 1 18. If the 
20 customer is a new user an account is created 120 and the customer is display their 

account information and password. 

8. The customer is displayed a confirmation page 122 to accept the purchase 
order and consent to the web banking payment method. 

9. An electronic bill is emailed 126 to the customer showing the order details, 
25 amount due, due date and instructing them to make payment to the payee using their 

assigned account number at their own bank. 



10. All transaction information 124 is tracked in the system database. 
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Fig. 7c illustrates in a flow chart the payment process. This method enables 
merchants to process bank payment notifications as follows: 

1. Customers visit their banks online, and pay their bills, using the account 
number and amount specified in the email 130. Note: The first time the user makes an 

5 online payment; they must add the payment receiver to the list of vendors in their bill 
list. 

2. On a scheduled basis 132, the banks send The payment receiver an electronic 
feed for the transactions completed. 

Options 1 -Automatic: The system receives 134 the files, parses them, extracts the data 
10 and populates the system database making the appropriate entries in the customer 
account tables. The process also notifies the user that the payee received a payment 
and that further action is required on their part if they chose the manual payment 
processing option to complete the transaction. 

Option 2- Manual: For smaller operations the bank feed can be received via fax and 
15 the database manually updated by an authorized administrator. The admin will use the 
debit manager interface to enter account number and amount received from the bank. 
The system will then update the database records. The process also notifies the user 
that the payee received a payment and that further action is required on their part if 
they chose the manual payment processing option to complete the transaction. 

20 3. Each customer can choose to allocate funds manually or let the account 
settlement module allocate money on their behalf using a First in first out (FIFO) 
system. 

4. If the customer chooses to allocate funds manually, then each time a payment 
is made at the bank, and the processing is completed by the system as outlined above, 
25 the customer is sent an email and is asked to revisit system and complete the 
transaction by allocating the funds appropriately. When the customer logs into their 
Wallet, they will see a list of their outstanding transactions and account balance. The 
customer manually allocates funds to each transaction. Transactions that have been 
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completed successfully are marked as payment complete. The remaining balance is 
credited to the customers account; outstanding transactions remain as payment 
pending. The customer can only allocate full payment against any specific 
transactions, partial payment are not accepted. 

5. If the customer makes a decision to allocate the funds automatically using 
FIFO, the Account Settlement module will process the payments daily using the 
following three scenarios. 

6. The amount deposited equals the amount owing 136 in the customers account. 
In such a case all transactions are processed, and marked as payment completed 138. 

7. The amount paid is larger than the amount owing on the customer account. In 
such a case all transactions are credited and their status is changed to payment 
competed. The remaining funds will remain in the customers account 140 and can be 
refunded or used at a later time to complete other payments against future 
transactions. 

8. If the money paid is less than the total amount owing on all transactions, then 
Account Settlement processes the transactions starting with the service that was 
purchased first, money is credited to each transaction and marked payment completed. 
Once the system determines that cash on hand is not sufficient to complete a 
transaction, the process stops. The remaining transactions retain their status as 
payment pending. The remaining funds stay in the users account. A transaction 
summary and account status is then emailed to the customer 142. 

9. The merchant has the option of sending reminder bills to customers with over 
due accounts. The bill sent to the customer will reflect the outstanding balance, and 
interest incurred and a total owing. 

The system also includes a default or configurable "Checkout" button. This 
graphic and text can be inserted in html webpages, emails or electronic documents to 
enable buyers to select the direct pay at my bank option. A default button is provided 
by MODASolutions however this is a configurable option for both The Checkout 
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button is The presentation and the wording on the checkout can be either supplied by 
MODASolutions or preconfigured by the merchant or provider. The preconfiguration 
includes presentation and text. 

Service Provider Tools 24 enable service providers to offer the system as a 
service to their merchant base. The Service Provide tools 24 allow an authorized 
system administrator to access and maintain information pertaining to their 
merchants, transactions billing, and merchant reimbursements. 

Using the Service Provider tool enables Service Providers: 

1 . to view, search, sort, and edit merchant account information, setup and 
tear down merchants belonging to that Service Provider; 

2. to view, search sort transaction information generated by their 
merchants; 

3. to view search sort customer account information; 

4. to generate merchant statements; and 

5. to reconcile settlement with merchants. 

The tools also allow Service Providers to: 

a. Retrieve records of all payments received for a specified period of 

time; 

b. Flag transaction records as " reimbursed" when payments of funds 
have been reimbursed to the merchants; and 

c. Generate a merchant statement 

Merchant Tools such as sales closing tools enable merchants to send 
notifications as follows: 

1. Systems notifications - enable merchants to select default system 
generated emails to be sent to buyers. As an example. The merchant can select a 
"Thank you for buying" email that is sent to consumers who paid directly. Another 
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example is when merchant can send a "reminder to pay" email for those with payment 
pending status 

2. Merchant defined notifications - enables merchants to compose and 
send emails to buyers who completed their payments or people who did not pay yet. 

5 These emails are not predefined and are written by the merchant and may include the 
opportunity for cross- selling or up selling. The system will support text-based emails 
and formatted based ones. 

3. Wireless SMS / MMS Systems notifications - enables merchants to 
select predefined system generated SMS or MMS messages to be sent to buyers on 

10 their mobile phones. As an example. The merchant can select a "Thank you for 
buying" SMS that is sent to consumers who paid directly. Another example is when 
merchant can send a "reminder to pay" SMS/MMS for those with payment pending 
status 

4. Wireless merchant defined notifications - enables merchants to 
15 compose and send SMS or MMS messages to buyers who completed their payments 

or people who did not pay yet. These emails are not predefined and are written by the 
merchant and may include the opportunity for cross- selling or up selling. 

Coupon issuing enables merchants to send coupons once the buyer has 
received the eBill. The coupon can include discounts that can be used to reduce 
20 payments or a credit that can be left in account for future purchases. Below is a 
walkthrough of how coupon issuing can work 

1. Buyer fills a shopping cart, checks out and selects direct payment from 
bank account. 

2 . Buyer receives eBill by email with the amount specified in the email. 

25 3. Merchant uses the couponing tools to issue a $100 discount coupon. 

The coupon can be issues at the same time the eBill is emailed or sent by the 
merchant at a later time to motivate the buyer to complete payment. 
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4. Buyer receives coupon and decides to pay. Buyer pays for entire 
amount less than the $ 1 00 coupon 

5. System processes transaction and matches the transaction with the 
account and settles the account 

5 Coupon creation and distribution module enables: 

1. a coupon to be created via the web manually and sent via email to the 

buyer; 

2. a coupon to be created via the web manually and sent via SMS to the 

buyer; 

10 3. a batch of coupons to be uploaded to the system and sent to buyers by 

email; 

4. a batch of coupons to be uploaded to the system and sent to buyers by 
SMS; and 

5. the merchant to define a credit coupon or a discount coupon. 

15 Discount coupons can be applied against an outstanding bill. Credit coupons 

can be applied any time after the coupon is issued. 

A Coupon Processing module enables the system to store, track, and process 
coupons sent to the buyer. The module maps coupon numbers to an account number 
held by the buyer. The module that enables discounts coupons to be matched against 
20 outstanding bills. On processing of transactions the number of coupons are matched 
against the eBill amount. The module enables credit coupons to be added to the 
buyer's account. The system processes the credit coupons and updates the balance in 
the buyer's account 
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Embedded payments in direct marketing campaigns can also be supported by 
system 10. The system enables merchants to preauthorize prospective buyers and 
send them marketing campaigns that include pre-assigned account numbers that 



I 
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enable the buyer to pay for the items enclosed in the campaign. The following is a 
walkthrough of the method: 

1 . Merchant compiles list of potential prospects 

2. Merchant sends campaign to list with details of product / service in the 
5 body of the email 

3. System assigns a predefined account number and assigns to the buyer 

4. Buyer receives email, reads information and then decides to pay 

5. Buyer uses pre-defined account to pay for merchant's product / service 

6. Buyer can click on a button that routs to a pre-filled form in which the 
10 user reviews information and then confirms a request for an eBill. The user then 

carries on with the payment process as defined throughout this document. 

7. Buyer has the opportunity to proceed and pay from their bank account 
without requesting an eBill. 

Recurring Payments enable merchants to define the payment schedule for 
15 recurring payments. The payment schedule can be defined on a weekly, monthly, or 
quarterly basis. The method enables merchants to track the number of recurring 
payments completed by the buyer. Example, merchant can view the admin reports and 
determine that customer x has completed 3 out of 7 payments. The merchant can also 
have the option to utilized any of the resources available by the system such as 
20 notifications and coupons. 

Leasing tools enable merchants to break down the amount of a transaction into 
multiple smaller amounts. An example of this scenario is as follows: 

1 . Merchant sells $ 1 000 dollars computers 

2. Buyer wants to buy computer but cannot afford full amount 
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Buyer agrees for the merchant's leasing program 
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4. Buyer selects leasing terms 

5. System sets up transaction as a recurring payment transaction and manage the 
eBills, the interest on the leasing as well as the conditions and policies in the event of 
a non-payment. 

Enterprise Deployment the system 10 can be supported as a software license 
that can be hosted on the web or deployed at the customer premise behind a firewall. 
A software license with installable tools to be deployed on standalone redundant 
servers and has all the modules to support direct payment from bank account. 

Backend Interfaces: 

1. enable merchants to pull data from IDM system via a set of interfaces as 
follows: 

a. XML interface 

b. Proprietary interface 

c. Email 

2. enable IDM to push the data via a set of tools as follows: 

a. XML interface 

b. Installable software at merchant premise that retrieves data from the 
system and presents it on the screen. 

3. A back end interface that include data from IDM containing information 
deposited in the database and passed to the system through the front end interface. 
The data includes the following: 

a. Transaction details 



b. Payment status 
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c. Sales closing information 

d. Coupon usage information 

Another embodiment extends the system to mobile phones, wireless devices, 
and PDAs that enables the purchase loop and the payment loop to be executed on a 
mobile device. In the form of an installable software module on a mobile device with 
menus and functionality that enables buyer to complete purchase and or payment loop 
on their mobile device and to manage their account status, payments and profiles. 

Wireless adaptation enables merchants to offer web-banking payments for 
purchases completed from a wireless device. 

1. The IDM engine can be built using any CGI Web enabled programming 
language, along with any data storage facilities. For the initial release of the engine 
JAVA, JSP, xHTML, Oracle are used to build the engine. There are several classes 
and database tables required to implement this engine. Also there are shell scripts and 
EDI used to transfer and extract the data between the banks and IDM. 

2. The IDM interface is also available for immediate use by clients with access to 
an IP enabled mobile phones. Since IDM wired interface is written using xHTML the 
translation to a wireless devise is instantaneous and requires minimal code 
modifications 

3. The IDM interface can also be developed to accommodate mobile devices that 
require a mobile interface. For this purpose IDM can be supported using different 
technologies such as J2ME Web services, ASP.NET, Python and other technologies. 

4. The mobile device can use navigation where a user can easily allocate funds 
using their mobile towards their IDM account. Once the payment is received by the 
IDM the data is processed in the same manner as before. An email is sent out as well 
as an SMS message (if client is set up with the service) instructing the client to 
allocate payments towards the transactions. The Wireless banking module is then 
invoked from the main menu, where a user is then displayed the balance in their 
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account and a list of transactions that are pending. The user can then select each item 
and hit the enter button on their phone. Once the button is selected, the appropriate 
tables are updated and the corresponding emails and SMS messages are sent. 

Referring to Fig. 8, there is illustrated communication with the system of Fig. 
1 for Internet card loading. Internet Card Loading is a method that enables merchants 
and consumer acquirers to load prepaid value cards using the EDM system. The stored 
value cards could be one of the following: 

1 . prepaid credit cards 

2. prepaid phone cards used for land line /mobile telephony 

3. prepaid value cards run and owned by the provider of the IDM system 



The following steps highlight the functionality for the system are illustrated in 
the Fig. 8: 

1 . user 80 visits merchant site 82 that is selling prepaid cards 

2. user selects card, and the amount of money to be loaded 

3. user receives an eBill 

4. user pays the eBill at their bank account using the pre-assigned account 
number 

5. Funds are now allocated in the user's account 

6. System 10 maps the account number to the prepaid card number 

7. mapping enables prepaid card to be used as desired by the user 80 
The internet loading can happen in multiple possible configurations: 

1 . The merchant acquirer 82 assigns an account to the consumer 80 and maps. the 
EDM account to the prepaid cards. 

2. The merchant acquirer 82 configures the system 10 to issue accounts that are 
equivalent to the prepaid cars. Once the account is loaded, there is no need for 
mapping between multiple accounts to be made 



25 



Ref No. 08-899058us 

The E)M system enables the system operator, merchant acquirers, to execute 
on novel methods to acquire merchants. These methods are detailed as follows: 

1. inverted value based pricing - merchant is charged on a per transaction value 
where the discount rate assigned is inverted to the value of the transaction. The higher 

5 the value of the transaction the lower the discount rate. For example, if a merchant's 
average business transaction is $1000 dollars, then the discount rate is 0.5%. If the 
merchant's average business transaction is $2000, then the discount rate is 0.25% 

2. flat based pricing - merchant is charged a flat fee per month or on a yearly 
basis regardless of the volume or value of the transaction. Example a large merchant 

10 is charged 100,000 dollars per year for unlimited number of transactions. A small 
merchant could be charged 5,000 per year for unlimited number of transactions. 
Different packages can be assembled based on the size, and type of merchant. 

3. Free internet loading - merchant is not charged for loading stored value cards. 
The revenue could then be derived from float, and breakage or other supporting 

15 revenue streams 



The IDM system enables the system operator to implement different business 
models by enabling the charging to be configured on a per merchant and per 
transaction basis. The following parameters can be configured by the merchant 
acquirer or the system administrator on a per merchant and per transaction basis. 
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1. 



merchant setup fee 



2. 



monthly service charge 



3. 



per transaction processing fee 



4. 



per transaction discount fee 



Each of these fees can be set to nullified to support different packages. 



